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Risk Title 


The Risk of Inadequate Design of Human and Automation/Robotic Integration is identified by 
the NASA Human Researeh Program (HRP) as a reeognized risk to human health and 
performanee in spaee. The HRP Program Requirements Doeument (PRD) defines these risks. 
This Evidenee Report provides a summary of the evidenee that has been used to identify and 
eharaeterize this risk. 


Risk Statement 

Given that automation and robotics must seamlessly integrate with crew, and given the greater 
dependence on automation and robotics in the context of long-duration spaceflight operations, 
there is a risk that systems will be inadequately designed, resulting in flight and ground crew 
errors and inefficiencies, failed mission and program objectives, and an increase in crew 
injuries. 

Risk Overview 

National Aeronauties and Spaee Administration (NASA) future missions will depend on humans 
interaeting with automated and robotie systems to aeeomplish mission goals. This will be the 
ease for both near- and deep-spaee exploration missions, ineluding near-Earth objeet (NEO) and 
planetary surfaee operations. It will be the ease for erew in spaee and eontrollers on the ground. 

To earry out NASA's vision, operations involving erew-robot and erew-automation interaetions 
will inerease substantially relative to eurrent operations. The systems required to support these 
operations will provide a highly diverse set of functions and will require diverse forms of 
control. The classes of robotic systems required for these missions will include dexterous, 
heavy-lift, and mobility systems. The required automation systems will span ground and flight 
systems and will support functions from controlling the habitat to conducting science 
experiments. 

These mixed-initiative systems will have to support multiple operators, varying time delays, and 
increased reliance on high and variable levels of automation. Human-robot teaming will be a 
cornerstone of future operations. Hence, robotic systems and their human interfaces must be 
designed to support all levels of human operation (direct manual control, shared control, and 
supervisory control). They must also support multiple robot operators in multi-agent team 
configurations, with those operators separated by time, space, or both. Similarly, the integration 
of automation systems with their human users requires supporting a variety of role divisions: 
authority and autonomy can be differently allocated between human and automation, and that 
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allocation may change dynamically depending on task or eontext. 


Ineffeetive user interfaees, poor system designs, or ill-advised funetional task alloeation 
eompromise mission sueeess and safety. There are gaps in our knowledge and experienee for this 
level of eomplexity of automated or robotie operations. Coneerning roboties, risk arises beeause 
we have limited experienee with teleoperation, time-delayed operations, and multi-agent 
paradigms. For example, poorly designed human interfaees ean result in a loss of situation 
awareness, eompromising mission safety and effieieney. Of speeial eoneern are losses of 
situation awareness that oeeur while a erewmember is in elose proximity to a robot, with the 
eonsequent risk to erew safety. Crew must be able to aseertain and understand the state of a 
robot, affeet or ehange its eommand, and override the system whenever neeessary. 

Currently, most work in spaee is performed by the erew, supported to some degree by on-board 
automated systems (e.g., for environment eontrol) and to a larger degree by ground-based 
Mission Control. As spaee missions’ seope expand in distanee and duration, and as the tasks 
exeeuted in spaee beeome more eomplex, inereased support by automation will be neeessary. 
Proper human-automation integration will be eritieal in spaee as well as on the ground. In spaee, 
more tasks will need to be eompleted by fewer people, with fewer external resourees and 
support. In addition, erewmemberss will have less training and experienee in any partieular 
aetivity eompared to the eorresponding member of a larger team with a speeialist for that 
aetivity. Further, the role of ground eontrol will ehange. Ground eontrol will need to provide 
different forms of support for the erew and vehiele, foeusing more on longer-term projeetions, 
modeling, antieipatory troubleshooting, and monitoring health of systems and erew. 

In short, mission eomplexity will inerease as mission familiarity and experienee deerease. This 
means that the ehallenges to effeetive design of automation and roboties, and of the human- 
system integration, also inerease. A eritieal aspeet to meeting automation design ehallenges is a 
foeus on integration (Terwieseh & Ganz, 2009). Automation/roboties must be well integrated 
into the proeess and the work flow it is designed to support. Further, eomplex missions require 
multiple automation systems and robots, as well as multiple people. Design with an awareness of 
how multiple “agents”, be they people, automation, or robots, ean and should eoordinate and 
integrate their aetivities is eritieal as well. Automation is never a direet matter of taking one task 
from human responsibility and simply assigning the identieal task to automation/roboties; 
automation ehanges the work, shifts times of peak human workload, and ereates new, often 
ehallenging tasks for humans sueh as supervisory responsibility. 

Many faetors affeet the adequaey of designs of human and automation/robotie integration, and an 
inadequate design ean produee many interrelated effeets. Effeetive intervention to minimize risk 
from inadequate design requires a multi-faeeted, systems-level approaeh. 
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One potential cause of poor design is an inappropriate acquisition process. That is, insufficient 
attention may be given to requiring sound human and automation/robotic integration in 
procurement or there may be inadequate methods for ensuring delivery of sound design, even 
with intent to require it. There may be insufficient attention to identifying the expected functions 
of the automation/robotic system or of the unexpected functions that users might ask of it. 

Design of effective human automation/robotic interaction (HARI) also requires an analysis of 
the way that functions should be distributed among humans, robots, and automated systems, and 
should consider the extent to which particular function allocations between humans and 
automation or robots should be fixed or flexible. Additional factors where poor integration may 
be manifest include: 

* inefficiency of interactions among operators (both ground and crew controllers), 
automation, and robotic agents; 

* incompleteness or inconsistency of situation awareness by the crew and the 
ground controllers; and 

* poor arbitration of command authority responsible for transferring control among 
multiple operators. 

The appropriateness of the design of human and automation/robotic integration also depends on 
how well it fits into the context of use, which may be quite variable. Context of use includes 
how controllers are trained, the extent and nature of human collaboration around system use, the 
level of controller fatigue or stress to be supported, and the urgency and dynamics of the tasks 
being carried out. These factors may interact and conspire such that safety-reduction from one 
factor increases vulnerabilities from another. All these factors and their interactions can be 
contributing causes of an inadequate design of HARI. 

The effects of an inadequate design of HARI may be immediate and direct, such as an operator 
selecting an unintended action or a robot harming an astronaut. They may also be long-term and 
indirect, such as an unusable design contributing to human stress or an unclear design resulting 
in operation of equipment in configurations that produce unnecessary wear. It is important to be 
able to measure the consequences of inadequate design much more sensitively than recording the 
occurrence of rare, extreme accidents. The negative impact of poor design may be measured in 
terms of task time, workload, use of consumables, occurrence of repairs to actions such as 
backtracking or redoing, as well as other objective and subjective performance measures. The 
key point is that poor design can lead to many different types of negative consequences and can 
be caused by multiple, interacting factors. 

Effective risk reduction requires a systems-level analysis of HARI. This is needed to understand 
and intervene on multiple interacting causes. We also need measures to assess the effectiveness 
of interventions. The evidence about risk reduction presented in this report is organized around 
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four types of causal risk factors, selected from the Human Factors Analysis and Classification 
System [HFACS) categories of error (Shappell,2000). This classification system attempts to 
identify the point or points in a causal chain of events that produced an accident, typically with 
behavior identified as an error after the fact. This approach focuses on explaining events after 
they happen, and providing a causal chain in this explanation. An alternative approach focuses 
on safety rather than risk reduction and on resilience rather than error (Hollnagel, Woods, & 
Leveson, 2006; Woods, Dekker, Cook, Johannesen, & Sarter, 2010). In the resilience view an 
effective design of integration would facilitate effective operation within safety boundaries, 
while allowing detection of and adaption to changes in safety boundaries possibly due to 
complex, unexpected dynamics. This newer perspective focuses on system-level and emergent 
properties, and considers the coupling and integration of distinct factors, such as needs analysis, 
procedure design, training, operating conditions, and many more. Nevertheless, the summary of 
evidence is organized here in accord with HFACS contributing factors to risk pertaining to 

1) Resource/ Acquisition Management including Assignment of Human and Automation 
Resources, 

2) Organizational Climate including perceptions of Equipment, and 

3) Technological Environment including 

a) Design for Automation and 

b) Human/Robotic Coordination. 

Without proper integration of human, automated and robotic functions, mission goals are at risk. 

Levels of Evidence 

Evidence presented in this chapter encompasses lessons learned from 50 years of spaceflight 
experience and ground-based research related to the risk of inadequate human and 
automation/robotic integration. A variety of evidence types is available, which differ both with 
respect to the method used to collect evidence and with respect to the context or domain of the 
evidence. Concerning method, evidence comes from both formal and informal methods. 
Informal methods include post-hoc reports of naturally occurring events (including incidents and 
accidents) and case studies. Eormal methods include systematic logging or survey of naturally 
occurring events, and interviews with or surveys of experts. The most formal method of 
gathering evidence is controlled experimentation. Some evidence is reliant on simulated data 
from models of human behavior, of automation or robotic system behavior, or of human-system 
interaction, particularly for circumstances in which it is hard to directly observe and gather 
empirical data. 

A summary of Eevels of Evidence may include, but not be limited to: 

• Post-hoc reports of naturally occurring events 

• Case study 
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• Expert data 

• Expert opinion 

• Spaceflight incident data 

• Terrestrial data 

• Modeling 

• Controlled experiments 

Concerning context or domain, relevant evidence for HARI may come from space operations 
(both in-flight and on-the ground), from aviation or other safety-critical work domains, or from 
other domains with extensive or advanced automation or robotics. Typically, it is difficult to 
conduct experiments in-flight, so experimental data is most likely to come from simplified tasks 
or related domains, while in-space data is more likely to come from case studies. 

Portions of the evidence consist of summaries of subjective experience data, as well as non- 
experimental observations or comparative, correlation, and case or case-series studies. It should 
be noted that some evidence in this report is derived from the Elight Crew Integration (ECI) 
International Space Station (ISS) Eife Sciences Crew Comments Database. Although summaries 
of ISS crew comments are presented as evidence, the raw comments in the Life Sciences Crew 
Comments Database is are protected and not publicly available, due to the sensitive nature of the 
raw crew data it contains. 

Evidence 

There is extensive evidence that poor integration design produces safety-critical errors. Some 
evidence comes from in-space applications. There is also a large body of evidence from analog 
domains, such as aviation and medicine, in which highly skilled users interact with complex 
technical systems. Evidence and information from analog mishaps is used to develop systems 
involving similar situations and skills. However, this reactive design stance primarily “chases 
old problems” rather than forestalling the new. A proactive design stance is particularly valuable 
because, unlike aviation, the experience-base in space is relatively small and circumstances of 
operations change from mission to mission. Thus, information from prior mishaps is only a 
partial guide to the many novel situations where we lack specific experience. Euture research on 
HARI will need to investigate those circumstances where we lack direct knowledge. Research 
will also need to develop methods for extrapolating knowledge from known to less-understood 
conditions and to integrate the extensive but sometimes fragmentary knowledge we have. 

Resource/Acquisition Management 

This section considers the ways in which high-level analyses and decisions influence the 
effectiveness of design, and the evidence that these influences have consequences for safety and 
efficiency. The better the methods for generating and testing design of HARI, the better the 
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resulting systems are likely to be. A key researeh need is the development of effeetive methods 
and tools that support generation and testing of HARI design. Researeh on how such methods 
can be effectively adopted in practice would also be valuable. 

The particular Contributing Factor in focus concerns allocation of functions among humans and 
automation. This requires identification of the scope of work to be supported and the functions 
within that work. If there is not an adequate identification of the work functions needed, no 
partitioning of functions can be very satisfactory. Thus, effective allocation of function depends 
on effective processes for needs analysis. The factors contributing risk are intertwined. 

Serious accidents involving automation in complex operations typically have multiple causes. 

An initial problem event may be caused by poor integration design, and the response to such an 
event may be exacerbated by poor integration in some other aspect of the system. For example, 
the challenge of managing an equipment failure can be compounded if information about system 
state is provided in a form inconsistent with how people need to use that information (e.g. 
difficulty in early diagnosis in Apollo 13, (Murray & Cox, 1990), cited in (Woods et ah, 2010)). 
Effective HARI affords multiple opportunities to detect and respond to risky situations. Good 
design of HARI must also support effectively carrying out the system functions. There are 
multiple possible conflicting goals in the design and operation of a complex system, for example, 
between safety and immediate productivity. Assessing trading-offs among competing goals is 
typical in complex work, which includes known and unanticipated risks. Good design of HARI 
should support people in effectively gathering and evaluating information to make appropriate 
decisions about goal tradeoffs, in off-nominal as well as nominal conditions. 

An effective process for interaction design requires sound analysis of the work to be supported, 
or needs analysis. This requires an understanding of mission operations, the particular functions 
that an automation/robotic system is supporting, and of how these functions coordinate with 
related functions. There are multiple methods for doing this. We use the broad term “needs 
analysis” to include a variety of analysis methods, including task analysis (Kirwan & Ainsworth, 
1992), Work Domain Analysis (Vicente, 1999), and Contextual Inquiry (Beyer & Holtzblatt, 
1997). Designing a useful system requires identification of the functionality that should be 
supported by the system. Kieras, (1996) suggests the primary obstacle in automation design is 
not writing code, but understanding the problem. This requires a strong understanding of 
required tasks and how the task functions should be allocated. This task and domain knowledge 
is essential for most current cognitive engineering analyses. Sherry and Ward (1995) found that 
the majority of aviation software code was dedicated to understanding and executing the correct 
automation situations and behaviors, which requires domain expertise. Once the functions are 
identified, sound design requires further analysis of what functions should be carried out by 
which agents (human or automation) in what circumstances, i.e., function allocation. Effective 
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automation design needs to be integrated with proeess or workflow design (Beyer & Holtzblatt, 
1997; Woods et ah, 2010). 

Onee an appropriate needs analysis has been conducted, this information needs to be effectively 
linked to the design, development, and evaluation processes, which are typically handled as part 
of software engineering or systems engineering. An explicit needs analysis should guide the 
requirements specification for an automation or software system. The needs analysis should be 
used to guide not only verification (that the implemented system matches requirements) but also 
validation (that the system serves the intended needs). The assurance that a system meets the 
intended needs is particularly important for safety-critical systems. 

A variety of methods exist for testing existing or prototyped HARI designs. Direct assessment by 
observing people using the system can be very valuable. However this may be impractical or 
excessively expensive for some complex, safety critical systems. Modeling provides a 
complementary assessment approach. Operations can be modeled both at the level of a task 
analysis and at the level of human performance. Systems can be formally checked for specified 
properties, such as occurrence of a particular unsafe state (Clarke & Wing, 1996). Various 
modeling methods from cognitive science can simulate human performance (Card, Moran, & 
Newell, 1983; Gray, 2008; B. E. John, Prevas, Salvucci, & Koedinger, 2004). Modeling is 
primarily applicable for an existing design, as evaluation, and few models provide direct design 
guidance. However, modeling a system as it is being developed has provided formative feedback 
used by designers that substantially contributes to the effectiveness of the final design (Gray, B. 
John, & Atwood, 1993). 

While the importance of needs analysis is widely recognized, at least in the research community, 
it is often done poorly or not at all. Methods maybe expensive, require subject matter experts, 
require coordination among stakeholders, or prove otherwise burdensome. The product of needs 
analysis may not be framed in a way that can easily guide the generation and testing of designs. 
Similarly, evaluation tools exist but often requirements for expertise and time may limit their 
adoption. Evaluations may not provide outputs in a form useful to consumers of results. We 
need research on development and adoption of methods. Lack of practical and effective methods 
to support consistent generation and testing of good HARI design makes it difficult to 
consistently produce good designs. Thus lack of good methods is the fundamental cause of the 
risks produced by inadequate design of human-automation and human-robotic interaction. 

Euture space operations provide particularly challenging circumstances for designing appropriate 
HARI: 1) Good HARI design is particularly difficult for new or emerging technologies, which 
are common in space exploration; 2) Bad outcomes result when risks from many sources 
combine. A design threat for which operators might successfully compensate in familiar 
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conditions may show through in novel, risky conditions where integration is most critieal to 
safety and effieiency; 3) Software in spaee typieally lags state-of-the-art, due to environmental 
testing requirements. This makes it diffieult to use what is known about effeetive designs and 
design process. 

We provide two broad illustrations of the magnitude of risks incurred by inadequate HARI 
before turning to more specific topics. 

Examples 

The Mir-Progress eollision is an example of a poorly designed operations coneept and 
insufficient needs analysis resulting in a near-catastrophe. The Russian spacecraft Progress 234 
collided with the Mir space station, causing the pressure hull to rupture, and nearly causing the 
Mir to be abandoned (Ellis, 2000; Shayler, 2000). The original operations concept was that 
Progress would dock automatically with the Mir. Crew responsibilities were primarily to cancel 
the approach (if necessary) and limited crew displays were provided. Crewmembers were later 
tasked to perform the docking manually, following a decision not to install automatic docking 
systems for each Progress spacecraft. This decision was not based on an adequate assessment of 
integrated human-system performance. It negleeted consideration of the types of information 
erewmembers would need to remotely control another vehicle. Moreover, the crew had no direct 
visual access to the approaching spacecraft from the command post, nor was range-rate 
information direetly available. Further, the crew was stressed from overly demanding workload 
and repeated system failures that demanded their attention and eontributed to redueed vigilance. 
The erew last reeeived formal training four months before the docking incident. Multiple causal 
factors contributed to this event (Ellis, 2000). Moving from retrospeetive to prospective 
analysis, ensuring a good match between the needed funetionality and the funetionality 
supported by automation is eritieal to suecessful operation. 


Figure 1 . Spektr module showing the 
damaged radiator and solar array on Mir 
(NASA photograph). 
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There is a history of human-automation interaction difficulties for commercial aviation attributable to 
inappropriate designs. The U.S. Federal Aviation Administration (FAA) and the European Joint Aviation 
Authority recognized an increase in accidents attributable to problematic interaction between flight crews 
and flight deck automation. The FAA released a report listing design deficiencies contributing to aviation 
incidents and accidents and made recommendations for improvement, including the need for new design 
and evaluation tools in 1996 {The Interface between Flight crews and Modern Flight Deck Systems, 
1996). Research from the design (C. E. Billings, 1997; Curtis, 1981; Leveson, 1995), the accident 
investigation (Mellor, 1994; Sarsfield, Stanley, Lebow, Ettedgui, & Henning, 2000), and the regulatory 
(BASI (Australian Bureau of Air Safety Investigation), 1999; The Interface between Flight crews and 
Modern Flight Deck Systems, 1996) are important. These communities have also illustrated the need to 
develop methods, tools, and techniques to identify and address human-automation interaction 
vulnerabilities as early as possible in the design process. Mishaps due to design errors (i.e., mishaps 
where automated systems performed as designed but aspects of the design contributed to the 
accident) are increasing (Sarsfield et ah, 2000). Although aircraft designs continue to improve 
and overall levels of safety are increasing, the proportion of mishaps attributable to design flaws 
is increasing relative to those due to other factors. 

Contributing Factor 1: Assignment of Human and Automation Resources 

Poor distribution of functions among humans and their tools results in inefficient and unsafe 
operations, threatening mission completion. It is important to determine which functions should 
be allocated to the machine and which to the human. Automation design decisions have 
traditionally focused on optimizing the capabilities of the technology rather than those of the 
combined human-machine system. Relegating the human to the role of system monitor is often 
ill-suited. Removing human operators from the control loop can lead to vigilance decrements, 
loss of operator situation awareness, poor feedback, and manual skill decay. 

Several researchers have developed taxonomies of levels of automation (LOA) ( Table 8.1, 
Sheridan & Verplank, 1978; Sheridan & Parasuraman, 2005). Endsley & Kaber (1999) 
developed a LOA taxonomy that breaks automation into 10 different levels, and can be applied 
to functions of specific tasks within a system. A task includes four functions: monitoring, 
generating, selecting, and implementing. The roles of these four functions are allocated to either 
the human or the computer, depending on the level of automation. Endsley and Kaber (1999) 
report a complex pattern of effects from a study using a simple analog of package processing 
work. They found that during normal operation, EGAs that combine human generation of 
options with computer implementation of a selected option produced superior overall 
performance. Specifically, this performance was better than the alternatives where only human 
implementation of options or only computer generation of options was allowed. Automation did 
not help decision-making, either. However, when automation failed, the relation of performance 
to automation level was different, and complex. This suggests that ideal allocation may be very 
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sensitive to the particular capabilities of the operators and the automation, and to the context of 
operation. 

Recent work focuses on how functions should be distributed and shared, using a framework 
based on collaboration or teaming. The Human-Automation Collaboration Taxonomy (HACT) is 
a recent framework for design and analysis of collaborative human-automation decision-making 
(Cummings & Bruni, 2009). The framework identifies three roles, of moderator, generator, and 
decider, which may be distributed between human and automation for any task. In an experiment 
using a mission planning task done by experts, performance was worst when the automation was 
the lead in generating proposals; performance was better when generation was lead by the 
operator or when operator and system shared responsibility. These findings, in conjunction with 
those of Endsley and Kaber, suggest that building automation that is “as good as humans” at 
generating possibilities may be particularly difficult. Another successful planning system 
allowed the system to first generate a candidate plan, which could then be edited by the human, 
though this project did not compare alternative automation control structures (Butler et ah, 

2007). 

Additional research is needed to provide the empirical base from which generalizations can be 
made. A vital but little explored area is distribution of functions across teams of people and 
system of automation, and the ways in which dynamic allocation is or is not effective. A 
particularly challenging issue is developing the theoretical framework to guide how findings 
from one situation can be generalized to another. In turn, such a framework could guide 
development of modeling tools for predicting effective function distribution early in design and 
before empirical evaluation is feasible. Tools and methods are needed for function allocation, as 
with the identification of needs and functions to be allocated. 

Organizational Climate 

Organizational climate is an important contributor to safety. One aspect of this is how humans 
perceive the automation with which they interact. The way operators view an automated system 
has a strong influence on how effectively the human-automation system functions. In this 
context, researchers have focused on the degree of trust and reliance that humans place on their 
automation. 

Contributing Factor 2: Perceptions of Equipment 

In a particular setting, an operator may have too much or too little “trust” in the system, and 
these situations may result in over- or under-reliance on automation, respectively. An example 
of over-reliance on automation, with serious outcomes, involved failure to detect that the global 
positioning system (GPS) component of the auto-navigation system on a cruise ship had failed. 
As a result, the Royal Majesty was run aground (Degani, 2004; Lee & See, 2004). Operators 
were complacent and did not effectively monitor whether the system was behaving as designed. 
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When trust is high, operators are likely to rely on automation, i.e., to act as indicated by alarms 
or hazard indicators, but may be too “compliant” and fail to respond to unidentified hazards or 
hazards incorrectly identified by the system (Sheridan & Parasuraman, 2005). 

When accidents do occur, their significance should be understood in terms of the policy of the 
operator, or operator calibration. The operator policy means the way the operator, in general, 
uses the automation. This might include how much time the operator spends monitoring the 
automation, or how often the operator does what is recommended by the automation. The 
optimal policy is not necessarily one in which the operator monitors or complies with the 
automation all the time: the operator may have other things that make demands on his or her 
time, and the operator may justifiably believe automation is not always to be relied upon. 
Calibration refers to how well the operator’s policy of use aligns with automation characteristics. 
Because any automation is imperfect, any system will produce some distribution of error types; 
for diagnostic systems this can be characterized as misses and false alarms. Assessing the 
accuracy of operator calibration, not the occurrence of an individual accident is important for 
understanding the design quality of HARI. Frequently, operator calibration is good (Lee & 
Seppelt, 2009) and air traffic control (ATC) is one domain where this has been extensively 
studied. Operator reliance on automation is sometimes affected by workload (Kirlik, 1993; 
Wickens & Dixon, 2007), and by sudden change in automation performance, as well as by 
superficial aspects of an interface (Lee & Seppelt, 2009). Additional issues may arise at the 
transition point between prior, manual control of a function to new, automated control, as this 
change typically requires a reorganization of the operator’s tasks (Sarter, Woods, C. Billings, & 
Salvendy, 1997). 

In general, it is challenging to determine the contextually appropriate, rather than designer- 
intended, use of automation. It may, however, be feasible to do this for diagnostic and warning 
systems, where most research on operator perception of automation has focused. Here, at least in 
principle, there is accuracy data that an operator might use for calibrating reliance. Even here, it 
is a challenge to measure accuracy of the automation and what the appropriate response to 
warnings should be. Effective integration might be viewed as the automation providing 
information to enable anticipatory action, rather than as alerts to impending collisions (Wickens 
et ah, 2009). Eew studies have looked at overall effectiveness of using automation or of 
operators’ choices for when to engage an automatic aid at all. In one study that did pursue this, 
Kirlik (1993) sought to explain why operators did not use an experimental autopilot to off-load 
tasks at peak work periods. Modeling of task demands suggested that operators’ strategies 
(including nonuse) were more optimal than that intended by the designer. 

Adaptive automation is a next step to managing change in authority and in determining what 
information is provided to the user. While this may be able to strategically aid operators, e.g. 
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when suddenly stressed by high workload, this ean also reduee transpareney, making it difficult 
for the human to determine the state of the automation or of the system controlled. 

Risk arises from poor HARI when the way operators use automation is not well aligned with the 
automation’s capabilities. This frequently has fallen outside the focus of automation design, 
since the intent is typically to build automation with high benefits (e.g. accuracy) and low costs 
(e.g. set up). Thus, design to support users in determining how, in context, the system is most 
effectively used is not often addressed. Policies stipulating use may be effective for routine 
procedures, but may be inadequate for unusual situations. Additional research is needed to 
understand both what determines the most effective use of a system in context and to understand 
how people decide how to use the system. 

Technological Environment 

Interaction with the engineered environment is central to human-systems integration. Both 
automation and robotics concern computer-mediated systems that typically act on the physical 
world. Integration or coordination with humans is a central concern for both. Nevertheless, a 
somewhat distinct set of issues and research has developed around each. Once the decision to 
include automation or robotics in a socio-technical environment is made, the design of its 
integration with humans strongly impacts performance 

Contributing Factor 3: Design for Automation 

This section reviews impacts not already addressed, specifically concerning transparency. 
Transparency is also closely related to quality of information display and to training, which are 
each discussed in separate reports. Interaction with the automation should be transparent, so that 
operators can easily tell the state and capabilities of the system. Lack of transparency may 
produce: 1) inability to determine the current state of the automation or of the system it is 
controlling, and 2) lack of understanding of what the automation can do. In turn, this leaves the 
user unprepared to diagnose or intervene in the automation behavior. 

Designing for transparency is very difficult for systems that are very complex and require many 
displays and controls. Kieras (1996) points out two strategies used for handling complexity: 
distributing displays and controls across physical space, as on older “switch and meter” systems, 
and distributing displays and controls across time, as with newer software-based systems, using 
multiple modes. 

In older electro-mechanical systems, displays and controls were fixed physical devices, and 
instrumentation was spread over the surfaces needed to contain it. In these systems, inadequate 
design led to errors because information was often widely and awkwardly distributed. A critical 
factor in the Three Mile Island events was display layout: a distributed and awkward 
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arrangement made the state of the system hard to grasp, and so failure diagnosis was diffieult 
(Leveson, 1995). 

In software-supported eontrol, the display and eontrol spaee is usually very limited. In many 
modem applieations, displays and eontrols are restrieted to a eomputer sereen (sometimes very 
small) with mouse and keyboard. Rather than spreading information aeross spaee, information is 
spread aeross time with different information displayed in the same spaee at different times. A 
system mode is a stmetured eolleetion of interaetion options usually used together. One mode is 
seleeted from a set of modes, depending on eontext. Modes are used with eleetro-meehanieal 
systems as well as “glass eoekpit” and other software-eontrolled systems, but mode eomplexity 
inereases with software-eontrolled systems. 

Mode related errors are known eontributors in aviation aeeidents and ineidents. Laek of 
transpareney often results from issues related to modes. There are two types of problems: 
diffieulty in telling what mode a system is in and diffieulty telling what a mode will do. For 
example, pilot training may only teaeh seleetive modes, leaving out unusual modes or those not 
used in airline operations poliey. Pilot performanee has latent problems, revealed in non-normal 
situations (Sarter & Woods, 1994). Problems ean result beeause the system was in a mode not 
expeeted or identified by the pilot, the pilot eould not prediet behavior in that mode, or both 
(Sarter et ah, 1997). In 1994, an A300 airplane erashed at Nagoya Airport. Prior to the erash, the 
mode had been inadvertently ehanged to “Go Around” rather than land. The pilot fought against 
the autopilot and was unable to gain eontrol. Laek of awareness that the mode had been 
ehanged, and inability to prediet how automation and human eontrol would affeet behavior in 
these eonditions were both likely eontributors (Sogame & Ladkin, 1996). 

On Apollo 10, at the end of the seeond pass over lunar landing site 2, the two erewmembers were 
preparing to separate the two stages of the lunar lander and return to the eommand module in 
orbit around the moon when the mode of the guidanee and navigation system was inadvertently 
ehanged by one of the erewmembers. A eouple of seeonds later, the other erewmembers reaehed 
up, without looking, and ehanged the mode of the guidanee system, whieh eaneeled the ehange 
that had been made by the first erewmembers. As a result, the lunar module. Snoopy, began 
firing thrusters in all axes, pushing the gyroseopes into gimbal look and making the navigation 
system useless until it was reset. The erewmembers then toggled the navigation system switoh 
again and, although he now put it into the mode it should have been in to start with, it made 
things worse. At this point the orew overrode the eomputer and took manual eontrol. The 
inoident lasted about 15 seeonds, during whieh Snoopy made eight oomplete rolls. It was 
estimated that if the erewmembers had not regained eontrol within another 2 seeonds, it would 
have been too late to avoid impaet with the moon. Without elearly eommunieated information 
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about actions and state changes of both automation and crew, there is real risk to safety from 
accidental operations (Shayler, 2000). 

An Airbus test flight with very skilled crew also ended in a crash following a combination of 
conditions that produced both unexpected mode change and inability to compensate for the 
autopilot behavior in this mode (Aviation Week and Space Technology, 1995); also discussed in 
(Sarter et ah, 1997). This case involved an automation-initiated mode change due to the extreme 
conditions of the test, and inadequate time to diagnose and recover from the control policy in this 
mode. Problems were compounded because automatic decluttering, which is designed to 
simplify the displays in an emergency, removed all flight mode enunciators from the display. 

This left the pilot with no visible indicator of control mode. In another incident, unexpected 
effects of disengaging the autopilot led to Pilot Induced Oscillation (PIO), resulting in passenger 
injury (Encounter with Wake Turbulence, Air Canada, Airbus A3 19-1 14 C-GBHZ, 2008); lack 
of understanding the effects of mode change was a probable contributor. 

Implicating mode issues in accidents illustrates their criticality, but accident analysis does not 
provide a method of systematic and controlled investigation of phenomena. Several laboratory 
experiments have investigated the extent and nature of mode errors. Sarter and Woods (2000) 
constructed challenging scenarios to be flown in high fidelity simulators. The realistic but 
challenging scenarios required 18 First Officers to respond to unusual conditions, including 
unusual automatically triggered mode transitions and unusual clearance instructions. Across 5 
unusual probe events requiring pilot action, only 39% of responses were accurate and timely 
while for 34%, appropriate action was never taken (Table 2, Sarter & Woods, 2000). This study 
shows that even with modern designs and expert users, mode issues can have a serious impact on 
performance, particularly when operating in challenging conditions. 

Risks from poor transparency concerning mode state and mode behaviors are most often 
triggered by some unfamiliar combination of conditions, frequently including operation in a less 
safe environment. This may result in mode changes triggered by the automation or by a partner, 
as well as by a key operator. An operator, such as the Pilot Flying, may then be unaware of the 
current mode and be in a mode whose behavior is less familiar, while also operating in 
dangerous external conditions. While the conditions that trigger problems may be rare in 
aviation, unfamiliar mode combinations and unsafe environments will occur more frequently in 
space. Complex automation is powerful in part because it provides multiple control policies, 
which can be selected based on circumstances. Yet managing different modes is a key locus of 
ineffective integration. Understanding design and design trade-offs in managing complex 
control policies is a critical area of research. Methods and tools to increase efficiency of 
research and for generalizing findings are also needed. 
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Contributing Factor 4: Human/Robotic Coordination 


Coordinating human and robotic activities for future space exploration ereates ehallenges in 
many areas, but partieularly for Human-Robot Interaetion (HRI). Most researeh in this field is in 
its infancy, as evidenced primarily by the fact that human teleoperation, supervisory eontrol and 
teaming have not yet been widely implemented in space, military, industry and the like. Current 
in-spaee applieations are limited to the Shuttle and Station robotic arms, and an experimental 
flight of the AERCam Sprint robot in 1997 (Pederson, et al, 2003), all of whieh are eontrolled by 
on-orbit erew via direct teleoperation. Surfaee exploration robots sueh as Sojourner, Phoenix 
and the Mars Exploration Rovers (MERs) have been used extensively for over a deeade but their 
operations are open-loop, where the human must send sequenees of eommands rather than aet on 
fed-baek information in real-time due to the long signal time delays between Earth and Mars. We 
will be faeing inereasing eomplexity of future robotie systems as we move from direet 
teleoperation to supervised teleoperation and autonomous eontrol, with both spatial and temporal 
distanees between operator and robotie agent. Employing human robot teams will require a level 
of eoordination not previously realized between teams of robotie eontrollers, astronauts and 
mission eontrollers. Without overeoming the eomplex and varied HRI ehallenges faeing the 
system designers, we are at risk of not fulfilling the roles envisioned of NASA human robot 
systems. 

Risk is inherent due to our lack of knowledge and experience with how best to design HRIs to 
meet the eapabilities required of future human-robotic (HR) systems. However, there have been 
many lessons learned from the years of Shuttle, Station and Mars robotic operations. MeCurdy 
(2009) deseribes the iterative proeess that evolved the tools used by the Mars robot operators to 
plan and exeeute commands. After taetieal proeesses were implemented, they found that they 
were not able to support the deadlines that the tasks demanded. Planning tools were developed 
to meet the necessary timelines, but these too suffered ineffieiencies (Norris, et ah, 2005). After 
applying human-eentered prineiples, several interfaee issues were identified. There were large 
numbers of tools designed by different groups for differing purposes, that were ineonsistent and 
non-eohesive, whieh led to steep learning curves as well as performanee issues. Their primary 
timeline tool was based on outdated legaey software and developed with a different user 
population in mind; this led to signifieant effeets on their ability to make or miss an uplink 
deadline. Modifieations were made to this tool for the Phoenix Mars Eander mission. 

Optimized roboties operations are eritical for the sueeessful exeeution of extravehieular aetivities 
(EVA) onboard the ISS. Aeeording to data contained in the ECI ISS Eife Seiences Crew 
Comments Database, this ineludes the proper set up and eonfiguration of the onboard Robotie 
Workstation (RWS) and subsequent aetuation and execution of arm operations. The RWS for 
both the Space Shuttle Remote Manipulator System (SRMS) and Spaee Station Remote 
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Manipulator System (SSRMS) consists of a laptop computer, translational and rotational hand 
controllers, three video monitors and a display and control panel. Robotics workstations onboard 
the ISS are currently located in the US Lab, Cupola and Japanese Pressurized Module (JPM). 
Although the workstation can be operated by a single crewmember, in practice, crewmembers 
prefer that RWS activities be conducted with two crewmembers. One person acts as the primary 
controller, and the second crewmember is dedicated to managing camera operations, observing 
procedures, and confirming the direction of motion. They report that this allows them to increase 
their situation awareness and maintain a system of checks and balances. They have noted that 
the second crewmember does not necessarily have to be another on-orbit crewmember and could 
alternatively be a ground crew operator, however this depends on maintaining real-time 
communication with Mission Control, which is not always possible. The crew have cited 
improvements that are needed to the HRI controls, including more camera views and assistive 
overlays. 



Figure 2. European Space Agency astronaut 
Leopold Ey harts, STS-123 mission specialist, 
and astronaut Greg Johnson, pilot, perform 
work at the robotics work station in the U.S. 
laboratory. Destiny. 



Figure 3. Completing an EVA activity using 
the robot arm with a crewmember on the end 
from inside the shuttle requires careful 
allocation of functions and task planning. 
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Given the already strained roboties erew resourees and the large number of robotie and EVA 
operations expeeted for ISS, ground eontrol is an attraetive method for off-loading on-orbit erew 
time and maximizing the effieieney of end-to-end ISS operations (Coleshill, et ah, 2009). In 
2005 during STS-I22/ISS lOA, the planned effieieneies were finally realized as a majority of pre 
and post operation eonfigurations for SSRMS were alloeated to ground eontrol. Adjustments 
had to be made to reduee the eonstraints on the step size of arm motions allowing greater 
movement distanees in less time. These were originally implemented by safety to reduee the 
duration of eaeh maneuver, thereby limiting the number of unplanned loss of eommunieation 
signals between the ground and the ISS. Task analysis was able to determine the best alloeation 
of operations between the on-orbit erew and the ground. This type of eoordination will be 
eritieal as eontrol of remotely loeated robotic agents becomes more commonplace in an 
environment of increasing time delay and loss of signal (LOS) events (Aziz, et ah, 2010). 

For Shuttle and ISS operations and in cases where the time delay allows, ground control should 
be used to the greatest extent possible to reduce EVA time and accomplishment risk. For surface 
operations, this could involve a robotic operator in a habitat controlling an external robot to 
maximize the efficiency of surface EVAs. Currently, some barriers to extensive ground control 
exist because mission controllers place a high level of restriction upon the type and methods of 
operation allowed until more experience is gained. Additionally, the robotic systems along with 
their human interfaces were designed for on-orbit use and are not tailored to the needs and 
limitations of a remote operator. At present, the range of operations is limited and while crew 
on-orbit time has been relieved, the overall timelines have not been reduced (Webb, et ah, 2009). 

The Special Purpose Dexterous Manipulator (SPDM), or Dextre is a two-armed manipulator 
mounted on the SSRMS as part of the Mobile Servicing System. It is designed to perform 
dexterous robotic maintenance, payload servicing, and other miscellaneous tasks. Even before 
the system was launched in 2008, it was determined that within the accepted operations 
constraints, the timelines associated with its use would be excessive and beyond the crew 
resources that were available. A Technical Interchange Meeting was convened in 2002 to look at 
the prohibitively long end-to-end timelines. They are due in part to robot design, wherein one 
arm is required for stabilization, resulting in tasks being reduced to single-arm tasks. There is 
also no direct operator viewing, large numbers of procedural steps, and robotic tool manipulation 
is required for almost all Removal and Replacement (R&R) situations (Caron, 2004). 
Additionally, procedures are entirely pre-planned and approved, leaving little to no ability to 
respond to real-time anomalies or contingencies. This plagued a recent SPDM activity wherein 
operations had to be halted for over a day while they re -planned based on an anomaly. Several 
enhancements such as auto-sequencing and targeting overlays are in the early stages of 
development to help mitigate these issues. 
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Figure 4. In June 2008, Dextre 
was moved atop the Destiny 
Laboratory Module of the 
International Space Station 
(ISS), completing tasks prior to 
the the STS-124 mission's 
deployment of Japan's Kibo 
pressurized science laboratory. 


Currie and Rochlis (2004) conducted a study using the SPDM trainer to assess the feasibility of 
ground control operations under a time delay, a condition that will become of primary concern 
for robotic operation as we move beyond Low Earth Orbit exploration. Astronaut test subjects 
conducted an Orbital Replacement Unit (ORU) R&R activity with simulated six and eight 
second telemetry and video time delays (LOS conditions were not modeled in this experiment). 
Crew found that they could easily adapt to the delays and all subjects were able to successfully 
complete the activity. Interestingly, more than fifty percent of the ground control operational 
time was spent not on motion command inputs via the hand controllers, but on manipulating 
displays, cameras, and controls to gain and maintain situation awareness. This implies that 
performance increases are to be gained from more effective interface designs (Carrie & Rochlis, 
2004). 

Human interface improvements such as augmented reality have also been investigated (Maida, et 
ah, 2007). Although a human-in-the-loop command mode is available for SPDM, it is operated 
almost exclusively using automated sequencing from the ground, where camera views and 
situation awareness information is at a minimum. Their results indicate that overlays improve 
performance in maneuvering an ORU in preparation for inserting it into a receptacle, and three 
performance metrics showed statistically significant improvements in prepositioning accuracy 
using overlays. 

While robotics operations conducted onboard the Space Shuttle and ISS involve minimal 
autonomy with ground crews supporting and monitoring all aspects of crew robotics tasks, future 
spaceflight missions will involve increased autonomy and potentially decreased ground support 
during robotics operations. Kadous, Ka-Man Sheh & Sammut (2006) highlight that teleoperation 
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is a vital consideration for robotics activities and interaction with robots. Successful robotic 
operations rely on optimized design of user interfaces. This includes the development of user 
interfaces that allow for varying levels of autonomy, cooperation and interaction between 
humans and robots (Kadius, et ah, 2006). 

The art of assessing human-robotic interfaces and the methods and metrics used to do so are still 
emerging. While specific, agreed upon attributes for human-robotic user interfaces do not 
necessarily exist as of yet, Kadous, Ka-Man Sheh & Sammut (2006) highlight several guidelines 
to consider. These guidelines are derived from previous design principles developed by Scholtz 
(2004). They include awareness, efficiency, familiarity and responsiveness. Awareness involves 
the proper presentation of information to ensure operators have a complete mental model 
regarding the robot’s internal and external state. This necessitates creating a balance to avoid 
overloading the operator with too much information. Efficiency involves requiring as little 
operator hand and eye movement as possible and ensuring focus of attention. Familiarity 
involves a focus on the inclusion of intuitive information and concepts that the operator is 
familiar with and an avoidance of the presentation of unfamiliar information. Finally, 
responsiveness guarantees an operator is receiving continuous feedback regarding operations. 

Keyes et al. (2010) similarly contend that overall awareness is key for the successful completion 
of robotics tasks. Robotic operations will often occur outside of the human operator’s line of 
sight. This requires the human to have acute knowledge of all aspects of the working conditions 
and environment that the robot will be operating in as well as the state of the robot (Keyes, et ah, 
2010). Drury, Keyes, and Yanco (2007) define this level of human-robot awareness by five 
individual characteristics, namely, human-robot awareness, human-human awareness, robot- 
human awareness, robot-robot awareness, and the human’s overall awareness of the mission 
(Drury, et al., 2007). Kadous, Ka-Man Sheh & Sammut (2006) contend that robot operations 
should embody the operator, while the operator in turn should strive to imagine themselves as the 
robot (creating a sense of ‘presence’), or in the same environment as the robot, during operations. 
However, this methodology can encounter barriers such as the varying morphologies between 
the robot and the operator, and issues with sensing and perception. Operators may encounter 
problems with control and interaction if they feel they cannot relate to or sense the robot’s 
operations. Ensuring complete situational awareness is available through the HRI is critical. 

Trafton, et al. (2005) also provide guidelines for the design of human-robot interfaces. They 
suggest a human-to-human interaction model, which involves using interactions between people 
as a guide to design the planned human-robotic interactions. While there are many aspects of 
human-to-human interaction, a desired characteristic of human-robotic interaction is a human’s 
ability to apply alternative viewpoints and reason from this perspective, although it may vary 
from their day-to- day point of view. Various forms of perspective taking can apply to a 
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multitude of tasks and situations. Although this seems to likely be a suceessful guideline for 
human-robot interfaee design, reeent literature and researeh rarely address perspeetive taking and 
robots. 

Trafton, et al. (2005) eondueted researeh to attempt to understand how perspeetive taking is 
already used or eould be applied to spaeeflight EVA. They observed and analyzed EVA training 
aetivities at the NASA Johnson Spaee Center Neutral Buoyaney Eaboratory (NBE) and 
determined that spatial-perspeetive taking was oeeurring during these aetivities. This involves 
sueh examples as the meaning of the word “down” having a totally different definition in a six 
degree-of-freedom EVA environment (where one would have to know what “down” was in 
relation to) as opposed to on the ground. This weightless operational environment ean ereate 
speeifie ehallenges from a spatial perspeetive. Based on this applied analysis, three guidelines 
were developed to assist with understanding and designing human-robotie interaetions from a 
human-human interaetion point of view. They inelude: 1) ensuring that all aspects of robotic 
representation and cognitive-like functioning (such as reasoning and perception) are as human- 
like as possible, 2) building cognitive systems for the interactions based on integrated cognitive 
architectures, and 3) applying heuristics and principles for collaborative activities that align with 
human expectations. Overall, similar to human-to-human perspective taking, a robot should be 
able to assume and adapt to multiple perspectives while performing tasks to allow for optimized 
human-robotic interaction. Lastly, the researchers discuss how the issue of collaboration 
between humans and robots is one of the most difficult aspects to study. Their analysis attempts 
to answer questions such as when to collaborate, when to ask for help, and how to respond to 
assistance. 

McIntyre, et al. (2003) have focused their research on the nature of teams, their interrelations, 
and how they develop team cohesion. While this research is in reference to human teams, these 
concepts can apply to interactions within human-robotic teams. Team cohesion can be defined 
by both social and task cohesion. Social cohesion involves the desire to achieve team affiliation. 
Task cohesion involves the efforts of the team to achieve tasks and goals together as a team 
(Craig & Kelly, 1999). McIntyre, et al. (2003) highlight a teamwork process model known as 
the “Dickinson-Mcintyre model” (Tedrow 2001) which can be mapped to the development of 
human-robotic teams. The model details seven components of teamwork which provide a 
framework that leads to optimized task performance. The elements include communication, 
team orientation, team leadership, monitoring, feedback, backup behavior, and coordination 
(Tedrow, 2001). 

Eerketic et al. (2006) address NASA’s “Vision for Space Exploration” (VSE) initiative 
established in 2004 and its primary goal of establishing a human-robotic program for future 
exploration. Unlike previous exploration programs, VSE places specific attention on human- 
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robotic interaction capabilities and on integration to enhanee exploration, safety and mission 
suecess. This is signifieantly important and complex given potential long duration and deep 
spaee missions that will involve inereased erew autonomy, limited eommunication and 
minimized dependence on ground support. Inereased relianee on human-robotic interaction built 
into future mission objeetives will lead to a signifieant ehange in the philosophy for the design 
and exeeution of missions. Crews will be expeeted to be eomfortable and familiar with robotie 
user interfaees, and these interfaees must optimally support mission objeetives (Ferketie, et ah, 
2006). 

Similar to many other researehers, Ferketie et al. (2006) highlight the eurrent laek and inereasing 
need for establishing standards to define effeetive human-robotic interaction and design 
interfaees. While human engineering and human-eentered design standards ean apply, speeifie 
guidelines are needed based on the unique demands of long-duration spaeeflight missions and 
the nature of interaetions and objeetives related to human-robotie operations. Developing HRI 
standards ean be extremely eomplex as most robots are developed with customized interfaees 
and methods of interaction, and the level of eoordination and eontrol required is often highly task 
dependent. In order to standardize these types of operations and interactions, common metrics 
and measures must be developed. This ineludes fundamental eommands, operations, and 
interfaces that lead to expected and similar responses from the robots. This will subsequently 
lead to inereased consisteney in robotic actions, operators’ familiarization and eomfort with 
control and operation of the robots, and deereased risk of errors and mission objective failures. In 
an effort to properly develop standards for human-robotic interactions in spaceflight missions, 
Ferketie et al. (2006) identify their own essential guidelines. These inelude; 

• define the eapabilities and limitations of humans and robots 

• develop user interfaees whieh are suited to the task at hand 

• address any related ehallenges to effieiency and operations to allow for human-robotie 
eollaboration 

• establish superior prototyping and evaluation methods 

These guidelines will allow for the evolution of human-robotie interaetion, inereased safety, and 
sueeessful, eollaborative task eompletion. 

Risk in Context of Exploration Mission Operational Scenarios 

Future exploration-mission seenarios will increase in duration and in distance from earth. This 
will require developing new teehnology, new work methods, and new ways of ensuring that 
these novel elements are suitably integrated. In particular, new automation and robotie 
teehnology and new ways of using technology to accomplish mission objects are needed. 
Missions earried out in spaee will need greater flexibility and less dependenee on ground 
support, and new interaetion between ground-based resourees and erew will also be needed. 
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Risks from inadequate design of human- teehnology interaetion will inerease as mission 
requirements beeome more demanding and as missions are earried out in unfamiliar 
eireumstanees substantially different from our experienee base. Human faetors prineiples will 
need to be extended and applied to reduee risk. 

Spaee operations are tightly eoupled, and probably will trend more so. That is, one event or 
aspeet of the system ean affeet many others, often quiekly or with limited ability to intervene 
effeetively. This means that problems may eompound and propagate extensively and rapidly. 
For example, a poorly eontrolled robot might damage a eraft or habitat; damage that might be 
ineonsequential on earth eould lead to a easeade of threats. Conversely, benefits from good 
design may propagate. If HARI supporting routine tasks is well-designed, it means tasks ean be 
done more quiekly and with less erew fatigue; in turn, this leaves the erew with more resourees 
to be better prepared to deal with safety-eritieal events. 

Good design is foundational to redueing integration risks, both of safety and of failure to 
eomplete missions due to ineffioieney or ineffeetiveness. While poor integration design may be 
eompensated by extensive training or other work-arounds, good design reduees eosts, inereases 
effieieney, and enhanees safety. Most spaee exploration missions are earried out through human 
use of teehnology (automation/roboties). Thus, the seope of impaet of the design of human- 
automation/robotie integration is very large. In turn, applying effeetive design methods and 
implementing effeetive designs ean have a very large, benefieial impaet on operational sueeess. 
Gaining the benefits of good design also requires effeetive implementation and evaluation. 

Conclusion 

The sueeess of future exploration missions depends, even more than today, on effeetive 
integration of humans and teehnology (automation and roboties). This will not emerge by 
ehanee, but by design. Both erew and ground personnel will need to do more demanding tasks in 
more diffieult eonditions, amplifying the eosts of poor design and the benefits of good design. 
This report has looked at the importanee of good design and the risks from poor design from 
several perspeetives: 

1) If the relevant funetions needed for a mission are not identified, then designs of teehnology 
and its use by humans are unlikely to be effeetive: eritieal funetions will be missing and 
irrelevant funetions will mislead or drain attention. 

2) If funetions are not distributed effeetively among the (multiple) partieipating humans and 
automation/robotie systems, later design ehoiees ean do little to repair this: additional 
unneeessary eoordination work may be introdueed, workload may be redistributed to ereate 
problems, limited human attentional resourees may be wasted, and the eapabilities of both 
humans and teehnology underused. 
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3) If the design does not promote aeeurate understanding of the eapabilities of the teehnology, 
the operators will not use the teehnology effeetively: the system may be switehed off in 
eonditions where it would be effeetive, or used for tasks or in eontexts where its effeetiveness 
may be very limited. 

4) If an ineffeetive interaetion design is implemented and put into use, a wide range of problems 
ean ensue. Many involve lack of transparency into the system: operators may be unable or 
find it very diffieult to determine a) the eurrent state and ehanges of state of the automation or 
robot, b) the eurrent state and ehanges in state of the system being eontrolled or aeted on, and 
e) what aetions by human or by system had what effeets. 

5) If the human interfaees for operation and eontrol of robotie agents are not designed to 
aoeommodate the unique points of view and operating environments of both the human and 
the robotie agent, then effeetive human-robot eoordination eannot be aehieved. 
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